1. Field of the Invention
The present invention relates to a data processing system and method of operation, and in particular to a data processing system for generating states of a model defined within a modeling application.
2. Description of the Related Art
Typically such a data processing system will run a software application in which a model can be defined by a number of equations, variables and constants. For example a spreadsheet application could be used to model the financial state of a company over a number of years. The state of the model might depend on a large number of variables, and typically the model will be responsive to information used to alter those variables, and hence to alter the state of the model.
Likewise, running the modeling application might result in a number of financial and other predictions indicating the success or otherwise of the modeling process. The user will generally wish to change a number of the input variables to produce a good set of predictions. However this is not always a straightforward task for the user.
The user's difficulty generally arises from the need to remember how the model variables changed and the result of those changes, before the next set of changes can be made. Typically, graphs may be used to help in this visualization process, e.g. giving financial and market share results over a number of years. Even so, after a number of variable changes, the user's memory of the actual shape of the graphs will quickly fade, making it very difficult to choose the optimum direction to change the values of the input variables.
Existing prior art techniques, such as "What-if" programming, allow the user to adjust the input variables, or alternatively to instruct the modeling application how to do so, and the user then judges the various outputs produced. Even if these techniques are useful in many cases, it is almost impossible to use them when there are more than four or five input variables to be set up. It is difficult to keep track of past experiments, and the user gets distracted by the mechanism of setting up the variables or the instructions for the experiments.
Other techniques, such as those used in "solver" and "optimizer" tools of existing modeling applications, are not useful in situations where the user cannot readily define the result that he/she is trying to achieve; moreover they only produce a single value as a result and can only be defined by a mathematical equation.
European Patent Application EP 0,628,918 describes a "Mutator" technique for controlling the input variables of a standard or special purpose modeling application. The basic Mutator concept is to let the system randomly alter the input variables of the modeling application within predetermined limits, and to then provide the new input variables to the modeling application to generate a new state of the model. This process can be repeated a number of times to produce a series of mutated states of the model, the user then being presented with a visual representation of this series of "mutated" states of the model. Based on this, the user can then select the best of the representations for a subsequent iteration of the mutation process. The decision as to which representations are "best" is a subjective decision made by the user, and will be dependent on the overall state of the model that the user is aiming to achieve. The states corresponding to the representations selected by the user are referred to as "parents", whereas the states produced in a subsequent iteration of the mutation process are referred to as "children".
Various features are described in the above referenced European patent application to be employed by the user when selecting parent states for a subsequent iteration. One feature allows the user to flag some of the states of the model as "good" or "bad", and this judgement is then used to steer or bias the mutation. Another feature allows the user to select and `marry` parent states to produce children that share characteristics of their parents. Typically, the user interacts with the mutation system by means of a selection device, such as a mouse, firstly selecting from a menu a characteristic, such as "good" or "bad", to be associated with subsequently selected representations, and then selecting the representations that the user considers to exhibit that characteristic, thereby associating that characteristic with the selected state(s). The user can then select another characteristic from the menu, and then make some further selections or modify one or more old selections. In this way the states selected as bad are discarded and disappear from the screen while the states selected as good are kept for use as parents in a subsequent iteration of the mutation process. Moreover, the user can apply weighting values to selected states, such as those state(s) selected as good. This would typically be done by selecting a weighting function from the menu and then clicking a number of times on such state(s), where the number of clicks on a particular representation equates to the weighting given to that state. According to the above prior art approach, the states selected as "good" would generally have an icon associated with them to indicate their selection, but would remain in their original position. Additionally numbers would be provided with the icons to indicate the weighting value given.
It is advantageous for the user to make use of the above features, since experience has indicated that the Mutator system operates most effectively when a user chooses several potential parents at each mutation step.
However, in spite of the above features facilitating a quicker generation of satisfactory mutated scenarios, they are not very easy or intuitive to use, and can be rather cumbersome. When the user is not only selecting parent states but also weighting (or "ranking") them, the above technique becomes particularly cumbersome, since the user has to select a weighting function and then revisit the selected states in order to apply the desired weighting to them. Indeed experience has shown that users often avoid using these separate features because of the user effort required.